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ABSTRACT 


The demand for quickly delivering new applications is 
increasingly becoming a business imperative today. Applica- 
tion development is often done in an ad hoc manner, without 
standard frameworks or libraries, thus resulting in poor 
reuse of software assets. Web services have received much 
interest in industry due to their potential in facilitating 
seamless business-to-business or enterprise application inte- 
gration. A web services composition tool can help automate 
the process, from creating business process functionality, 
to developing executable workflows, to deploying them 
on an execution environment. However, we find that 
the main approaches taken thus far to standardize and 
compose web services are piecemeal and insufficient. The 
business world has adopted a (distributed) programming 
approach in which web service instances are described 
using WSDL, composed into flows with a language like 
BPEL and invoked with the SOAP protocol. Academia 
has propounded the AI approach of formally representing 
web service capabilities in ontologies, and reasoning about 
their composition using goal-oriented inferencing techniques 
from planning. We present the first integrated work in 
composing web services end to end from specification to 
deployment by synergistically combining the strengths of 
the above approaches. We describe a prototype service 
creation environment along with a use-case scenario, and 
demonstrate how it can significantly speed up the time-to- 
market for new services. 
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1. INTRODUCTION 


The demand for quickly delivering new applications is 
increasingly becoming a business imperative today. For 
example, given the intense competition in the telecom 
sector, mobile telephony service providers need to con- 
tinually develop compelling applications to attract and 
retain end-users, with quick time-to-market. Often, if a 
competitor introduces a new service, the service provider 
must offer a similar or better service within days/weeks, 
to avoid losing customers. Also, a service provider can 
attract enterprise customers by offering custom-developed 
value-added services that leverage its telecom and IT in- 
frastructure. Enterprise customers typically offer signifi- 
cantly higher margins than consumers, and are thus more 
attractive. Service providers therefore need tools and 
standards-based runtime platforms to quickly develop and 
deploy interesting applications for their clients. This would 
assist in their transition towards “on demand”, responsive 
businesses. 

Much of this service/application development is currently 
done in an ad hoc manner, without standard frameworks 
or libraries, thus resulting in poor reuse of software assets. 
When a new service is needed, the desired capability is 
informally specified. An application developer must then 
create this capability using component services available in- 
house or from known vendors. This process is essentially 
manual. For example, if a mobile service provider wishes 
to offer a taxi-request service to its users, the developer 
must pick a third-party taxi service (with an advertised 
network interface) apart from in-house services like location- 
tracking, accounting, etc. and design a workflow that 
delivers the required functionality. The dynamic nature 
of the environment impacts the development process as 
well. For example, new taxi services may become available, 
offering better and/or cheaper services; physical changes in 
the network or environment may necessitate a redesign of 
the flow, etc. 

Web services have received much interest in industry 
due to their potential in facilitating seamless business- 
to-business or enterprise application integration [22, 27]. 


Web services offer standardized interface description, dis- 
covery and messaging mechanisms. Also, the programming 
tools and runtime environments for web services have now 
matured. A component-oriented software development 
approach where each software is wrapped as a web ser- 
vice would offer substantial benefits in the mobile service 
provider’s scenario. Mobile user applications often rely on 
several, relatively simple building blocks — user profile look- 
ups, address books, location-tracking services, accounting 
and billing services, etc. Many of these building blocks 
are already in place, but they are not easy to reuse and 
integrate into new applications because they are not built 
using standardized frameworks or component models. This 
leads to high development costs, and substantial time-to- 
market for new services. This could be alleviated by building 
applications using the service-oriented architecture (SOA) 
paradigm, using web services as the underlying abstraction. 

We find that two different approaches have been taken 
to standardize and compose web services. The business 
world has adopted a distributed systems approach in which 
web service instances are described using WSDL, composed 
into flows with a language like BPEL‘, and invoked with 
the SOAP protocol. Academia has propounded the AI 
approach of formally representing web service capabilities in 
ontologies, and reasoning about their functional composition 
using goal-oriented inferencing techniques from planning 
[16]. These approaches by themselves are piecemeal, and 
insufficient. The former has focused on the execution aspects 
of composite web services, without much consideration for 
requirements capture and the development process. The 
latter approach has stressed on the feasibility of service 
composition based on semantic descriptions of service ca- 
pabilities, but its output cannot be directly handed off to a 
runtime environment for deployment. 

In this paper, we demonstrate how web services compo- 
sition can be leveraged for business process integration, by 
synergistically combining the strengths of both the above 
approaches. The main contributions are: 


e To the best of our knowledge, we present the first 
end to end web services composition methodology 
that, given a formally specified requirement for a new 
service, stitches together semantically-annotated web 
service components in a BPEL flow that delivers the 
required function. 


e We propose a principled two-stage web services compo- 
sition approach leveraging the differentiation between 
web service types and instances. This helps in handling 
different goals, different data, different rates of change 
of data at each stage, and different means to optimize 
them. It allows us to achieve scalability. 


e We describe an end to end working prototype: (a) 
Ontology matching, composition at type level with 
service matchmaking (b) Composition at physical 
level with instance selection (c) Deployment onto a 
decentralized workflow orchestration infrastructure. 


The rest of this paper is organized as follows. In the next 
section, we describe a business process integration scenario 
and motivate the role of web services composition. We then 


‘http: //www.ibm.com/developerworks/webservices/library / 
ws-bpel/ 


describe our approach (Sec. 3) followed by details on its 
main aspects — logical composition (Sec. 4) and physical 
composition (Sec. 5). Section 6 illustrates our solution for 
the use-case scenario. In Sec. 7, we provide a summary of 
related work. Finally we conclude with some directions for 
future work. 


2. A MOTIVATING EXAMPLE 


Service providers, like telcos, are increasingly targeting 
businesses as customers because of the higher margins 
and longer-term relationships. Suppose a telco wants 
to enable an enterprise customer to use its telecom and 
IT infrastructure by creating and deploying services that 
automate the customer’s business processes. As an example 
the telco is attempting to automate a typical Helpline (or 
call center) for a washing machine manufacturer. 

A customer calls in to report a problem with her washing 
machine. This problem needs to be assigned to an agent 
for resolution. If the problem is such that it could be 
solved over the phone, a desk-based agent at the call center 
will be assigned. Otherwise, we need to find an agent in 
the field who can visit the customer and fix the washing 
machine. The service provider would like to create a set of 
web services that automate parts of this process to whatever 
extent possible, and keep aggregating these components to 
create higher-level composite services. Once such a software 
infrastructure is developed, the telco could offer it as a 
service to various enterprise customers (appliance manufac- 
turers, software vendors, etc), with minor customization. 
Figure 1 summarizes the workflow in this Helpline scenario. 
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Figure 1: Helpline Service. 


Here is a sampling of the component services that may be 
available in the service provider’s infrastructure: Location 
tracking, SMS, Call Setup, Agent Expertise data, Problem 
Classification, Agent Selection. Some of these provide telco- 
specific functions such as delivering SMS text messages, 
location tracking of mobile phones, etc. Others are specific 
to the application domain, e.g. problem classification. 

A developer needs to create a set of higher-level services 
using these components. Consider for example a location- 
based agent selector service (Fig. 2). Given a customer’s 
location and a list of agents out in the field, this service 
needs to select one of the agents, based on proximity to the 
customer’s residence. This selected agent will then be asked 
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Figure 2: Location-based Agent Selector Service. 


to visit the customer and fix her washing machine. The 
bottom half of Fig. 2 shows how this can be done by creating 
a flow linking together several component services, feeding 
them the right inputs, etc. Doing this manually takes 
time (and the developer has to know which components 
exist, and how to connect them up). Instead, we provide 
a tool that discovers the relevant services from amongst the 
available ones, and creates the control flow between them. 
The available services are semantically annotated, providing 
meta-information about their functionality in the context of 
a domain model. The developer only needs to (formally) 
specify the requirements of the service to be created. The 
tool can then generate a flow, and with some developer 
inputs, deploy the flow on to a runtime infrastructure. This 
should lead to quicker service creation, and thus faster time- 
to-market for new services. 

Further, the newly created Location-based Agent Selector 
(LAS) service itself becomes available as a component. It 
can now be reused in creating other flows, such as the one in 
Fig. 1. Each new service thus enriches the infrastructure and 
makes the developer’s task easier in future. We will use the 
LAS service as a running example to explain the phases in 
the composition process. Our service creation environment 
however includes a domain model and ontology for the 
entire Helpline Automation scenario, and we demonstrate 
the automated composition of the complete flow of Fig. 1 in 
Sec. 6. 


3. SYSTEM OVERVIEW 


Our service creation methodology, based on web service 
composition techniques, consists of the following steps: 


1. Service Representation: Representing the available 
services and their capabilities. 


2. Requirements Specification: 
functionality of a new service. 


Specifying the desired 


3. Composition: Constructing a composition of available 
services that provides the desired functionality. 


4. Composite Service Representation: Representing the 
new composite service and its capabilities so that 
it can be programmatically deployed, discovered and 
invoked. 


In previous work a similar process has been applied at 
different levels of abstraction, none of which individually 
yields a practical solution. Our system takes an end to 
end view that synergistically combines the AI approach and 
the distributed programming approach currently adopted 
by academia and the industry respectively. It drives the 
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composition process right from specification of the business 
process, through creation of desired functionality using 
planning techniques, through generation of a deployable 
workflow by selection and binding of appropriate service 
instances, to finally deploying and running the composite 
service. This integrated solution achieves the best of 
both worlds and provides scalability to the composition 
process. We have built a service creation environment that 
realizes this approach in terms of the following phases of 
composition: 


1. Logical Composition: This phase provides func- 
tional composition of service types to create new 
functionality that is currently not available. 


2. Physical Composition: ‘This phase enables the 
selection of component service instances based on non- 
functional (e.g. quality of service) requirements, that 
would then be bound together for deploying the newly 
created composite service. 


This basic approach to automating the process of service 
creation is illustrated in Fig. 3. A Service Registry con- 
tains information about services available in-house as well 
as with participating 3rd-party providers. The capabilities 
of each available service type are described formally, using 
domain-specific terminology that is defined in a Domain 
Ontology. When a new service needs to be created, the 
developer provides a Service Specification to the Logical 
Composer module. Driven by the specified requirements, 
the Logical Composer uses generative planning-based auto- 
mated reasoning techniques to create a composition of the 
available service types. Its goal is to explore qualitatively 
different choices and produce an abstract workflow, i.e. 
a plan (assuming a feasible plan exists) that meets the 
specified requirements. 

In order to turn the plan into a concrete workflow that can 
be deployed and executed, specific instances must be chosen 
for the component services in the plan. The Physical 
Composer uses scheduling and compilation techniques in 
selecting the best web service instances to produce an 
executable workflow. The focus is now on quantitatively 
exploring the available web service instances for workflow 
execution. It queries the registry for deployed web service 
instances, to accomplish this task. 


The workflow generated by the service creation environ- 
ment must then be deployed onto a runtime infrastructure, 
and executed in an efficient and scalable manner. This 
is especially important in environments like that of a 
mobile service provider, where the number of end-users 
is likely to be very high. The state of the art is to 
execute the workflow using a workflow engine such as 
WebSphere Process Choreographer”, with data flowing back 
and forth from this engine to the component web services. 
Our Execution Environment instead orchestrates the 
workflow in a decentralized fashion, with partitions of the 
flow executing concurrently, in network-proximity with the 
component services they invoke. These flow partitions are 
generated automatically by a Decentralizer tool, using static 
analysis of the input BPEL flow. The communication 
amongst these partitions is designed to minimize network 
usage, while retaining the original flow semantics. This, in 
conjunction with the added concurrency, results in better 
scalability and performance. For more details on our 
Execution Environment please refer to [5, 18]. In this paper, 
we will focus on the Logical and Physical composition stages. 


4. LOGICAL COMPOSITION 


Figure 4 depicts our system for implementing the four 
steps of composition during Logical Composition. Available 
service types and their capabilities are represented in a 
Service Capabilities Registry. An Ontology captures the do- 
main model. We use IBM’s SNOBASE? as the management 
system for our ontology and the service capabilities registry. 
Specification of the desired service is supplied to a Logical 
Composer module that first gets it verified for syntactic 
correctness using a Validator module. The Matchmaker 
module allows querying the service registry for available ser- 
vices. Based upon the validated specification, Planner4J 
retrieves the set of candidate services using the matchmaker. 
The Filter module helps in pruning the set of candidate 
services before Planner4J uses planning techniques to create 
the composite service. We next discuss the issues that arise 
in each step of logical composition. 
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Figure 4: Logical Composition. 


4.1 Representation of Service Types 


To enable automatic discovery and composition of desired 
functionality, we need a language to describe the available 
web services. This can take place at two levels — web service 
types and web service instances. At the logical composition 


“http: //www.software.ibm.com/wsdd/zones/was/wpc.html 
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stage, the composition process typically involves reasoning 
procedures. To enable those, services need to be described 
in a high-level and abstract manner [12]. Therefore at this 
stage it suffices to describe the capabilities of the types 
of web services, using semantic annotations. The second 
level of description becomes important in the physical 
composition stage where individual running services need to 
be identified for deploying the workflow. Once the language 
is known, the basic terms used in the language have to be 
drawn from a formal domain model. This is required to 
allow machine based interpretation while at the same time 
preventing ambiguities and interoperability problems. 

The DARPA Agent Markup Language (DAML, now 
called OWL)‘ is the result of an ongoing effort to define 
a language that allows creation of domain models or con- 
cept ontologies. We use it to create the domain model 
using which services are described. The OWL-S markup 
language [19] (previously known as DAML-S) is also being 
defined as a part of the same effort, for facilitating the 
creation of web service ontologies. It specifies an upper 
ontology of services that defines the structure of a service 
description. It defines that a service presents a ServiceProfile 
(i.e. what the service does), is describedBy a ServiceModel 
(i.e. how it works) and supports a ServiceGrounding (i.e. 
how to access it). 

Currently, OWL-S is designed to describe a single web 
service instance [19]. This is easily observed since the 
ServiceModel and ServiceGrounding aspects are specific to 
an instance of a web service. However, we believe that the 
type of a web service needs to be described independent 
of individual web service instances. This helps in working 
with large collections of web services — categorizing them, 
supporting multiple views, etc. [12]. In our present solution 
prototype, we use the ServiceProfile model of OWL-S to 
represent web service type definitions. The task of providing 
descriptions for specific web service instances is deferred to 
the physical composition phase. 

We have also developed a proposal to separate the 
representation of web service type definitions from instance 
definitions by enhancing the OWL-S upper ontology to have 
a ServiceType class hierarchy in addition to the Service 
hierarchy, as described in detail in [11]. Similar approach 
of separating type definitions from instance definitions has 
been used successfully in data models for distributed systems 
management |17, 1]. In future, we plan to incorporate the 
proposal and thereby use the same modeling language for 
representing both the service types and instances. 


4.2 Requirements Specification 


In order to create a new service, the developer should 
describe the required functionality as well as non-functional 
constraints such as throughput, response time, cost etc. We 
again use OWL-S for representing the requirements in IOPE 
terms, because the result of the composition is also a service. 
The developer is presented with a graphical user interface 
using which she can specify these requirements. The tool 
maps these to OWL-S for internal processing. 

In keeping with our philosophy of qualitatively composing 
the plan before focusing on the quantitative optimization is- 
sues, the tool processes the requirements incrementally. The 
preconditions and effects are logical terms and sentences, 


“http: //www.daml.org 
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Figure 5: Logical Plan for the LAS service. 


and are used during planning in logical composition’. The 
inputs and outputs are expressions involving general data 
types (e.g. integers, strings, algebraic expressions) which 
are used during instance selection and flow concretization in 
the physical composition phase. It is possible to incorporate 
numeric inputs and outputs during planning as well — this 
approach to planning is called metric planning [6]. Exploring 
the feasibility of metric planning for end to end web service 
composition would be an interesting area for future work. 

For the LAS composite service, the precondition (or 
the initial state of the composition problem) asserts that 
CustomerLocation is known and the effect (or the goal 
state) is to find the agent (AgentID) nearest to the customer 
location. 


4.3 Composition through Planning 


AI Planning deals with finding a course of actions that 
can take an agent from the initial state to a goal state, 
given a set of actions (legal state transformation functions) 
in the domain. Formally, a planning problem [30] P is a 
3-tuple < I,G,A > where I is the complete description 
of the initial state, G is the partial description of the goal 
state, and A is the set of executable (primitive) actions. 
An action sequence S (a plan) is a solution to P if S can 
be executed from J and the resulting state of the world 
contains G. A planner finds plans by evaluating actions and 
searching in the space of possible world states or the space 
of partial plans. Logical composition of web services can be 
cast as a planning problem by using the description of web 
services as actions, and forming initial and goal states from 
the specification of the service to be built along with the 
domain model [16]. 

For our service creation tool, planning for web services 
has some unique characteristics (refer to Fig. 4): 


e The nature of planning is limited contingency planning. 
The value of all logical terms may not be known in 


°Services can be matched using arbitrary sentences as 
defined with OWL-S 1.1 but for planning, we use a state 
representation consistent with the STRIPS assumptions[30]. 
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the initial state (e.g. whether Agent needs to be desk- 
based or in the field) but they can be found at runtime 
using sensing actions. Plans of contingent planning 
problems have branches corresponding to different 
outcomes that sensing actions may find. However, the 
user may not be interested in all branches — which 
are exponential in the number of unknown terms — 
but only in specific branches. For the rest (usually 
unimportant or unlikely cases), the user may manually 
insert a default branch. We have implemented such a 
contingent planner in the Planner4J framework [25]. 


e Filtering is needed to remove irrelevant web services. 
Since the number of web service instances in a registry 
could be very large, the number of web service types 
can also be large. Given a goal specification, the 
Filter finds services of potential relevance to the goal 
without actually searching for the solution. Relevant 
services are those that can either contribute to the 
goals (at least one effect unifies with a goal) or to 
the preconditions of any service which can potentially 
contribute to the goal. 


e Our Matchmaker [7] matches the preconditions of 
a web service with the effects of another up front. 
Another approach may be to perform matchmaking 
as needed during planning [23]. This can support 
more expressive matching (e.g. involving expressions 
of initially unknown terms) but at the cost of slower 
performance due to frequent reference to the ontology 
unifier. 


e We provide incomplete plans on request. If no com- 
plete sequence of actions is possible from the available 
services for a given requirement, planning can still help 
the user scope down the composition request or point 
to missing capabilities in the ontology. The planner 
sorts the search space of non-solutions based on a 
heuristic distance to goal. The plan with the lowest 
such distance gives us a candidate plan for further 
development. This is especially valuable when the 
ontology development has not stabilized. 


With these features planning is scalable, efficient and user 
friendly. We illustrate with some empirical results. On 
a contingent problem having a 7-step plan, with the filter 
enabled, the planner can return a solution in 4 seconds when 
100,000 irrelevant service types/actions are present, whereas 
it takes an hour without the filter. If the user chooses specific 
branches, the planner can leverage it for better performance 
— in an experiment where 3 branches were specified on a 
contingent problem with 100 sensing actions (2'°° possible 
branches), the planner takes 90% less time by leveraging this 
information rather than exploring the whole search space. 

In Fig. 5, the planner was invoked for the LAS service. 
Recall that the initial state asserts that CustomerLocation 
is known and the goal is to find the agent (Agent ID) nearest 
to the customer location. The output of the tool is a 4-step 
plan that can accomplish the goal. The created service is 
added to the service capabilities registry by the user. 


4.4 The Abstract Workflow 


The generated plan is a sequence of time steps, where each 
time step may have concurrent actions. Since plans can have 


branches which are contingent on specific conditions (called 
branch context) being met, actions are labeled with their 
context. The default context for an unconditional action is 
true, always valid. 

The plan is translated to the workflow representation of 
BPEL, a language for expressing interactions and message 
exchanges between partner entities. It can be automatically 
interpreted and executed by a workflow engine. A BPEL 
specification can be abstract or executable depending on 
whether binding information has been excluded or included. 

We render the generated plan as an abstract BPEL 
workflow since web service instance information is not 
known at this stage of the composition process. The actions 
in the plan are mapped to corresponding invoke activities in 
BPEL and organized into branches by inserting appropriate 
switch and case activities. 


5. PHYSICAL COMPOSITION 


Abstract 
Workflo 


Í Matchmaker le 


Physical n | = i 
S r S Data 
Dictionary 
Service |` = 


Compose Selected 
| Instances 


Instances 
BPEL 
Generator Registry 
WSDLs for the £ 
selected Instances 


Workflow | 


Figure 6: Physical Composition. 


In this phase, the abstract workflow for the composite 
service is fed to the Physical Composer, which binds each 
service in the workflow to a concrete service instance. The 
process of matching each service type to a corresponding 
instance, and then orchestrating between the set of instances 
in the resulting workflow is a non-trivial matchmaking 
problem. The problem has been addressed extensively for 
web services and involves a number of issues related to 
data flow orchestration, data type and invocation protocol 
matching, QoS matching and SLA composition. While some 
of these issues can be resolved in an automated manner, 
others might require manual intervention from a developer 
supervising the composition process. We next describe each 
of the steps involved in the Physical Composition stage, 
illustrated in Fig. 6. 


5.1 Representation of Service Instances and 
Requirements 


As in Logical Composition, we require a representation for 
service instances and composition requirements to facilitate 
Composition. It has been established that directory services, 
such as UDDI, are important but insufficient for this 
purpose [9] and need to be complemented with matchmaking 
facilities like symmetry of information exchange between 
services and their consumers, the ability of each party 
to describe requirements from the other party, a rich 
language to describe services’ and consumer demands, and a 
methodology to choose efficiently among competing service 
instances. 

To this end, we use the Web Services Matchmaking Engine 
(WSME) [9] — an engine capable of matching complex 
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entities, and a Data Dictionary tool for defining the 
language for the matching process. Matching is performed 
between service instances and requirements specified by the 
consumer. In our case, the requirements come from the 
abstract workflow and additional matching criteria specified 
by the developer performing the service composition. 

The engine is deployed as a Web service that receives 
queries and advertisements from the two parties involved in 
matchmaking. Each party essentially submits a description 
of itself and the demands from the other party. The Adver- 
tisement is submitted by the provider to WSME and is long 
lived, remaining in WSME until it is explicitly withdrawn 
by the provider or until the application server is stopped. 
The advertisement contains the following information: (1) 
MyType - this specifies the advertisement record-type. (2) 
YourType - this specifies the record-type expected to be 
submitted by the consumer query. (3) Properties - a 
list of the properties defined as MyType. Some of those 
properties may be defined as dynamic properties by the 
provider evaluated at runtime. (4) Rules (optional) - what 
the provider requires from the consumer. 

A Query submission is sent from the consumer to WSME 
and is transient, terminating after initiating the match- 
making process and bringing it to its conclusion. The 
query contains the following information: (1) MyType - this 
specifies the query record-type. (2) YourType - this specifies 
the provider’s advertisement record-type that the query is 
looking for. (3) Properties - a list of the properties defined as 
MyType. (4) Rules - what the consumer requires from the 
provider. The descriptions and demands can be dynamically 
created, deleted and modified in the form of properties and 
rules respectively, using a Data Dictionary tool. 

The WSME rules allow both sides to select the other party 
they wish to deal with by specifying their eligibility. A 
rule is a WSME script that is evaluated at matchmaking 
time, resulting in a Boolean value. A rule can refer to the 
properties of the two parties whose advertisement and query 
are involved in the matchmaking process. Example of a pos- 
sible consumer rule is the following: return(my.MaxCost < 
your.cost). A problem arises if a rule refers to a property 
that was not supplied. To avoid such a situation, the WSME 
Type system defines the mandatory list of properties that a 
submission must provide; the data dictionary contains those 
definitions. 

We illustrate the Data Dictionary definitions used for 
composing the Helpline Service discussed in Fig. 8. Each 
service instance needs to advertise itself to the WSME 
service instance registry using the advertisement definition. 
Each advertisement record contains basic information like 
the service name, service type, method name and WSDL 
information, along with QoS-specific metrics like (expected) 
response time, throughput and cost of invoking the particu- 
lar instance. Each query record specifies the method name 
and service type that needs to be bound to an instance along 
with additional rules that are specified by the developer 
supervising the composition process. 


5.2 Matchmaking and Instance Selection 


We employ a two-step approach where, in the first step, 
we use the WSME Matchmaker to select one or more can- 
didate instances that match the requirement specifications. 
Since a specific service type can be matched with more than 
one instance, we next adopt a heuristic-based approach to 
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Definition of query 
submission record type 


Definition of advertisement 
submission record type 


Figure 7: Advertisement and Query Formats for 
Helpline Service. 


select one among the conflicting instances, to complete the 
matchmaking process. 

The WSME matchmaking process is a two-way or sym- 
metric process - it brings together matching advertisements 
and queries by applying the rules of each party to the 
description of the other, thus allowing both parties to 
‘select’ each other. A matching advertisement is called an 
offer. If more than one offer is available, they are collected 
together. Zero, one or more matching offers are sent to the 
consumer. For further details on the matchmaking process, 
the interested reader is referred to [9]. 

Next, we deal with those service types that have more 
than one matching offers (instances) from WSME. While 
there are many ways to perform the instance selection, 
we chose to employ a greedy heuristic approach to solve 
the problem. In particular, the Instance Selector finds 
instance binding assignments that optimize certain quality 
of service metrics. For the current prototype, we focus 
on commonly used QoS metrics like cost, response time 
and throughput. We assume that values of these metrics 
(as advertised in WSME) are statistically guaranteed. If a 
service type has multiple matching instances, we choose an 
instance based on the optimization criteria specified by the 
developer supervising the composition process. 


5.3 BPEL Generation for Composite Service 


Now that each service type in the abstract flow is bound 
to an instance, the BPEL generator produces a (concrete) 
BPEL workflow that can be deployed onto a runtime 
infrastructure, to realize the composite service. 

We first generate the WSDL description for the composite 
service. It provides the name and interface of the composite 
service and describes the port types for stitching together 
the component services. Once the WSDL has been gener- 
ated, partner link types are defined, linking the component 
services. The next step is the generation of the BPEL flow. 
Components are invoked in the manner described by the 
abstract workflow. The composite service accepts inputs 
from the user that is fed to the first component service and 
sends an output from the last component service back to 
the user. We introduce variables that capture the output 
of one service and provide it as input to the next. Specific 
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<invoke name= "'invoke—GetAgentMobileNumbers" 
partnerLink="link2" 
portType="'GetA gentMobileNumbers" 
operation="'GetAgentMobileNumbers" 
inputVariable="variable1" 
outputVariable="variable2" / > 


<invoke name= "invoke—LocationTracker" 
partnerLink="link3" 
portType="'LocationTracker" 
operation="LocationTracker" 
inputVariable="'variable2" 
outputVariable="variable3" / > 


<invoke name= "'invoke—DistanceCalculator" 
partnerLink="link4" 
portType="'DistanceCalculator" 
operation="'DistanceCalculator" 
inputVariable="'variable3" 
outputVariable="Vvariable4" / > 


<invoke name= "invoke—OptimalAgentSelector" 
partnerLink="link5" 
portType="'OptimalA gentSelector" 
operation="OptimalA gentSelector" 
inputVariable="'variable4" 
outputVariable="variable5" / > 


Figure 8: BPEL code for the LAS service. 


details for each component service are obtained using the 
WSDL description for the corresponding instance, present 
in the WSME service instance registry. 

Though BPEL and WSDL are XML-based standards, we 
do not manipulate XML directly. We use an Eclipse Mod- 
eling Framework (EMF) model of BPEL (WSDL) that is 
automatically created from a BPEL (WSDL) schema®. The 
model provides in-memory representation of constructs and 
support for persistence to files (serialization) and loading 
from files (de-serialization). BPEL and WSDL manipulation 
become significantly simplified with the corresponding EMF 
models. 


Note that the BPEL generated might not be readily 
deployable on a workflow engine. This is due to the fact that 
the code for messaging between component services needs 
to handle issues like (input/output) type matching and 
transformation, mismatch in invocation protocols that are 
used (synchronous vs asynchronous), ordering of parameters 
etc. While the BPEL workflow acts as the template for the 
composite service, it needs to be examined and possibly 
modified by the developer to ensure that the data flow 
between component services is handled properly. In the 
current prototype, this is done by allowing the developer to 
edit the BPEL workflow before it is actually deployed. We 
also make the observation that the handling of some of these 
matching problems could be delegated to the matchmaking 
engine (WSME), and we plan to investigate this approach 
in the future. 

Figure 8 illustrates part of the BPEL code generated by 
the Physical Composer for the LAS service. It is composed 
of the four component services described in Sec. 2. Further, 
once physical composition is done, the WSDL description of 
this new service is added to the WSME instance registry, and 
can be later used in the composition of some other service. 


Shttp://www.eclipse.org/emf 


£ IBM Service Composition Tool zio x} 


Service Name HelplineService 


Description Given customer problem description attempts to resolve it using agents 


Physicaladdress 
ProblemCategory 
Problenmescription 
ProbleniIMLForm 
ProblenResolutionStatus 
Problemficket 
ProblemficketID 
Product ID 

K 


(http: 7 Amn. ibm. c/ “| 
(http: / Amn. ibn. ci 
(http: / Aan. ibm. c 
(http: faz, ibm. c 
(http: / Amn. ibn. ci 
(http: / Ann. ibn. c. 
(http: / Amn. ibn. c 
(http: / Amr. ibn. c) 
gi 


Preconditions 


z 


TELE. 


PhysicalAddress 
ProblemCategory 
Problenescription 
ProblenHTMLForm 
ProblenResolutionStatus 
Problemficket 
ProblemficketID 


(http: / mmr. ibm. c| 
(http: / Amme. ibm. c| 
(http: / fm. ibm. c! 
(http: / Amn. ibm. c| 
(http: / fame. ibm. c| 
(http: / Amn. ibm. c 
(http: 4 Ann. ibm. c| 


Effects 


(http: / fra. ibm. cl 
Pi 


£ IBM Service Composition Tool 
Workflow for service: HelplineService 


Code_| visual | 
Begin 
invoke WebInter faceProblenReportingService 
invoke CreateProblenficketService 
invoke ProblemClassi ficationService 
if (agentmoderemote) { 

invoke GetCustomerLocationService 


invoke Proh edhyent! alServicel 
= 
invoke Getiig & 9 S 
invoke AgentNotificationGeneratorService 
invoke TextToSpeechService 
invoke PhoneService 
invoke AgentService 
} else { 
invoke ProblemBasedigentRetrievalService2 
invoke GetAgentContactNoService 
invoke GetCustomerContactNoService 
invoke CallSetupService 


End 


Generate BPEL 


Discard | | Add Service | Exit 


(b) 


Figure 9: (a) Specifying input in the Composition Tool. (b) Logical Plan for Helpline Service. 


6. COMPOSING THE HELPLINE SERVICE 


We now discuss how our service creation tool can be used 
for composing the Helpline service described in Sec. 2. Re- 
call that the Helpline service consists of multiple components 
services like the LAS service, Message Delivery and Call 
Setup services. By way of running example, we showed how 
an executable workflow is created for the LAS service using 
the tool. The user can add the composite service to the 
service registry so that it is available for reuse. 

For developing the Helpline service, the user may choose 
to use the tool to explore basic services available, build ap- 
propriate composite services, and finally build the Helpline 
service. Alternatively, the user could ask the tool to build 
the Helpline service at the outset using the available services, 
and let the tool search through the set of possible plans. 
We expect the user to prefer the former approach, when 
the scenario is large and the user wants to control the 
composition. 

We have approximately 100 terms in the ontology and 
25 service types. Assume that the previously created 
composite LAS service has been added to the registry. 
Now the tool is invoked for the overall Helpline service 
with a precondition of ProblemHTMLForm, and the effect 
of ProblemResolutionStatus as shown in Fig. 9(a). The 
Logical Composer produces the plan shown in Fig. 9(b). 
Note that the LAS service is reused. The plan containing 
LAS service is selected over alternative plans without it, 
because the plan’s heuristic cost is less”. Finally, the Physi- 
cal Composer takes the abstract workflow and generates the 
appropriate BPEL (similar to Fig. 9). 


7. DISCUSSION AND RELATED WORK 


The literature on web service composition is extensive, 


"Designing heuristic functions so that user intent is 
respected is an active area of research in Hierarchical Task 
Network planning [8]. 
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consisting of promising results and many challenges [28, 
27]. To put it in perspective of this paper, we organize 
this section around design approaches for end to end 
composition, logical composition and physical composition. 


7.1 End to End Service Composition 


In AI planning, the potential advantage of resource 
abstraction whereby causal reasoning is decoupled from 
resource reasoning is well-established [26]. Our work can be 
seen as applying the same idea to web services composition. 
Specifically, we differentiate web services at the twin levels 
of web service types and instances. Our phased approach 
is easier for the user to work with and limits the impact of 
frequent deployment and runtime changes on the goal-driven 
composition. 

A planning-based phased approach has been used in 
[2] where an end-to-end system is described to construct 
workflows for manipulation of scientific data, which are 
executed on Grids. The domain involves composition at 
three levels — application domain level where appropriate 
applications are first selected, then an abstract plan is built 
with a planner, and finally it is detailed based on grid 
execution details. Two main differences with our work are 
that (a) they do not use ontologies while they recognize the 
need, and (b) the plan/workflow representation is simpler 
during logical composition — sequential, while we can handle 
branches as well. As our output is in BPEL which also 
has support for loops, exceptions and other behavioral 
constructs, the physical stage can be even more expressive. 

In [29], executable BPELs are automatically composed 
from goal specification by casting the planning problem as 
a model checking problem on the message specification of 
partners. The approach is promising but presently restricted 
to logical goals and small number of partner services. In 
contrast to our top-down approach, Mandell and MclIlraith 
[13] extend a BPEL engine to support runtime service 
selection using a semantic discovery server. 


7.2 Logical Composition 


The literature on composing services based on annotations 
(semantically organized in ontologies or otherwise) has 
taken two paths. One direction is disambiguating similar 
annotations using domain meta-data, rules, etc. The 
other direction is on methods to combine services whose 
annotations match based on some notion of similarity. 

In [20], matching of web services from a directory is 
formalized based on various inexactness measures. In 
[12], the authors have identified the information that a 
Semantic Web Service must expose in order to fulfill the 
objective of automated discovery, composition, invocation 
and interoperation. 

SWORD [21] was one of the initial attempts to use 
planning to compose web services. It does not model 
service capabilities in an ontology but uses rule chaining 
to composes web services. 

Sirin et al. [24] use contextual information to find 
matching services at each step of service composition. They 
further filter the set of matching services by using ontological 
reasoning on the semantic description of the services as well 
as by using user input. They attempt to overcome lack 
of support for service types in OWL-S by creating a class 
hierarchy of Service Profiles. A new sub-class is created for 
each value of an IOPE parameter. 

There are three problems with their approach. First, a 
large set of values for an attribute of a service would result 
in generation of that many classes. Second, to represent 
a functionality with multiple attributes a huge number of 
services, one each for a set of possible values of all attributes, 
would have to be represented as derived classes. Third, 
new classes need to be added to the ontology every time 
a new type of service is introduced. A cleaner approach 
that separates representation of the service definitions from 
service instances has already been described in Sec. 4. 

Web Services Modeling Ontology (WSMO) is a recent 
effort for modeling semantic web services in a markup 
language (WSML) and also defining a web service execution 
environment (WSMX) for it. Our logical composition 
approach is not specific to any particular modeling language 
and can adapt to newer languages. 


7.3 Physical Composition 


Several standardization proposals aimed at providing 
infrastructure support to Web service composition have re- 
cently emerged including SOAP, WSDL, UDDI, and BPEL. 
There has also been a lot of interest in the area of dynamic 
Web service and QoS-based workflow management. Pre- 
vious efforts in this area like eFlow [4] have investigated 
dynamic service selection based on user requirements. Zeng 
et al. [31] propose that the choice of component services 
in the plan be made at run time for optimality. Instead 
of making local choices at each step of the composition, 
the focus is on optimization at a composite level based on 
a generic QoS model (based on price, duration, reliability 
etc.) and established linear programming techniques. Other 
proposals such as METEOR [3] and CrossFlow [10] have 
considered QoS models for workflows along four dimensions 
namely time, cost, reliabilty and fidelity. Finally, there has 
been a considerable effort in the Web service community in 
identifying the challenges in workflow orchestration between 
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component services. In [14], the authors consider the 
problem of service composition as a problem of software 
synthesis where algorithms for matching and composition 
are based on Structural Synthesis of Programs (SSP) [15]. 
The SSP language is used as an internal representation 
language for automated service composition, while DAML-S 
is used as an external language for describing Web service 
properties. 


8. CONCLUSION 


We have described a two-step methodology for end to end 
composition of web services by semantically annotating web 
service components, as well as a prototype that demon- 
strates this methodology in a domain-specific scenario. 
Service developers can maintain a registry of web services 
that goes beyond the traditional UDDI by incorporating 
semantic descriptions of the components. When a new 
service requirement arises, it can be expressed in the context 
of a domain ontology. Our service creation environment can 
then be used to generate potential workflows for achieving 
the desired functionality reusing existing web services. This 
automation of the discovery process results in significant 
reduction in the time-to-market for the new service. 

There are two key innovations in our solution. First, we 
decouple web service composition into logical and physical 
composition stages that address complementary integration 
issues. The first stage focuses on the feasibility of functional 
composition while the latter deals with efficient execution 
of the resulting composition. Second, we use scalable 
and optimizing techniques in each stage that can adapt to 
changes in the service creation environment. 

In the future, we plan to integrate the service creation 
tool with a larger service development and execution in- 
frastructure. In order to do so, we wish to enable more 
interactions with the developer to stitch together message 
flows between the component services and, if required, refine 
the abstract /BPEL workflow for the composite service. Fur- 
ther, in the current solution, if the service composition fails 
for any reason, the composition process simply fails and the 
developer has to figure out the reasons for failure. Efforts are 
ongoing to enable a procedure to classify composition failure 
at different stages under different conditions, and then give 
a feedback of possible causes and suggests remedies to 
overcome the failure. This would serve as a decision-support 
tool that can be used along side a service composition 
tool. We also plan to transition to OWL 1.1 (currently 
in Beta stage) that provides support for rules. This would 
enable us to express richer pre-conditions and effects while 
representing service capabilities. For physical composition, 
we will continue investigating different instance selection 
heuristics for QoS matching, not only at the service instance 
level but also at the level of the composite service. Finally, 
we want to explore a feedback—based approach where the 
service creation tool interacts with the service execution 
infrastructure, to adapt and optimize based on changes in 
the execution environment. 
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